第十八章：你的角色不只是職稱：擴展影響力的關鍵

副標題：《BART - 角色 (Role)》

引子：故事中的場景

在《綠洲計畫》的第二十二章，當團隊的協作框架（邊界和權威）搭建起來後，艾佛勒將目光投向了構成這個框架的最基本單元——人。他發現，儘管流程順暢了，但許多成員對自身工作的理解，依然停留在狹隘的「功能執行者」層面：工程師只關心寫碼，QA只關心找錯，PM只關心傳話。

為了打破這種「角色固化」，艾佛勒沒有進行理論說教，而是設計了一系列巧妙的「角色互換」練習。他讓後端工程師大衛，坐到代表「客戶」的空椅子上；他讓開發工程師馬克，去體驗一天QA的工作。這些看似「遊戲」的活動，卻深刻地觸動了團隊成員，幫助他們擴展了對自身角色的認知，並開始自發地承擔起更大的責任。這正是對BART模型中「R - 角色」維度的深度干預。

理論溯源：從舞台劇到組織生活

「角色」的概念，天然地與戲劇聯繫在一起。社會學家厄文·高夫曼 (Erving Goffman) 在其著作《日常生活的自我呈現》中，就提出了著名的「戲劇理論 (Dramaturgy)」，認為社會互動就像一場舞台劇，每個人都在不同的場景中，扮演著不同的角色，並試圖管理自己在「觀眾」（他人）心目中的印象。

在組織發展領域，對「角色」的探討，則更側重於其功能性和心理性。

• 功能性角色 (Functional Role): 這指的是由組織賦予的、寫在職位說明書上的正式職責和任務。比如，「軟體工程師」的功能性角色，是設計、編寫和測試代碼。

• 心理性角色 (Psychological Role): 這指的是個體在團隊互動中，不自覺地承擔或被他人賦予的非正式角色。這與我們之前討論的「榮格原型」高度相關。比如，某個人可能總是扮演著「和事佬」（照顧者原型）的角色，或者「挑戰者」（小丑原型）的角色。

BART模型中的「R - 角色」，則綜合了這兩個層面。它不僅關心「你的職責是什麼？」（功能性），更關心「在這個系統中，你如何定位自己？你如何運用你的才能和影響力，來為整個系統的『主要任務』服務？」（心理性與系統性）。

理論精解：它到底在說什麼？

一個健康的組織系統，需要其成員對自己的角色，有一個清晰、靈活且與主要任務對齊的認知。當角色出現問題時，通常表現為以下幾種情況：

• 角色模糊 (Role Ambiguity): 成員不清楚組織對他們的期望到底是什麼，也不知道該如何做才能算是「成功」。這會導致焦慮、低效和缺乏方向感。

• 角色衝突 (Role Conflict):

  • 個體內衝突： 一個人被賦予了相互矛盾的期望。比如，PM安娜既被期望能滿足業務方「快速上線」的要求，又被期望能滿足工程師「穩定高質量」的要求。

  • 個體間衝突： 兩個或多個角色之間，因職責不清或目標不一而產生矛盾。

• 角色固化 (Role Fixation): 成員對自己角色的理解過於狹隘和僵化，只願意做「職位說明書上寫的那些事」，拒絕承擔任何額外的、有利於團隊整體目標的責任。這就是所謂的「穀倉思維」(Silo Mentality)。

擴展角色認知，其核心是推動成員從「我的工作 (My Job)」的思維，轉向「我們的事業 (Our Work)」的思維。

應用解析：書中的安排

在第二十二章中，沒有去修改任何人的職位說明書，而是通過一系列體驗式學習 (Experiential Learning) 的活動，來促成團隊成員內在的角色認知轉變。這種方法遠比單純的告知或要求更有效。

1. 「客戶的椅子」——引入系統中最重要的角色： 這個設計巧妙地將那個最重要，卻又常常在內部會議中「缺席」的角色——客戶——實體化了。當工程師大衛被迫從「客戶」的視角發言時，他對自己「工程師」角色的理解，立刻就從「為技術負責」，擴展到了「為用戶體驗負責」。

2. 「一日QA」——通過換位來打破壁壘： 他沒有召開一場「請大家尊重QA」的會議，而是直接讓開發去「成為」QA。這種親身體驗，勝過千言萬語。馬克在親手執行了繁瑣的測試用例後，才真正從內心深處，理解了QA的痛苦和價值，也因此重新定義了自己作為開發，「內建質量」的責任。這是一種極其深刻的同理心培養。

3. 重新賦能PM——從「傳話」到「引航」： 他與CTO一起，明確地為PM這個長期處於「角色衝突」中的崗位，進行了重新定位和賦能。他們賦予了安娜「產品CEO」和「首席Why講述者」的新角色，並給予了她相應的權威和支持。這不僅解救了安娜，也為整個開發團隊提供了一個清晰的「指南針」。

4. 聚焦於「擴展」，而非「否定」： 艾佛勒的所有設計，都不是在否定成員們原有的專業角色，而是在這個基礎上，幫助他們看到自己的角色，如何能與一個更大的系統目標相連。他幫助工程師意識到，自己不僅僅是一個寫碼的，更是一位產品質量的守護者和用戶問題的解決者。

實踐指南：你也可以這樣用

你可以在團隊中，創造一些輕量級的機會，來促進角色的擴展和相互理解。

• 練習一：「角色訪談」： 邀請團隊成員，兩兩一組，互相進行一次15分鐘的「角色訪談」。可以問一些問題，比如：「在你的一天中，最讓你感到有成就感的部分是什麼？最讓你感到挫敗的部分是什麼？」「如果可以，你最希望我（作為另一個角色）在哪方面能更好地支持你？」

• 練習二：「演示日」(Demo Day) 的角色擴展： 在團隊的產品演示會上，不要總是讓PM一個人來演示。可以嘗試讓負責開發具體功能的工程師，親自來演示他/她的工作成果，並解釋這個功能為用戶解決了什麼問題。這是一個鍛煉工程師「產品思維」和「溝通能力」的絕佳機會。

延伸思考

• 思考題： 在你的團隊中，是否存在一種普遍的「角色固化」現象？人們是更傾向於說「這不是我的事」，還是更傾向於說「我們怎樣才能一起把這件事搞定」？你認為造成這種現象的原因是什麼？